Skip to content

Conversation

@CharlesDuboisSAP
Copy link
Contributor

@CharlesDuboisSAP CharlesDuboisSAP commented Nov 21, 2024

Context

AI/ai-sdk-java-backlog#112

oneOf / anyOf / allOf with multiple possible options should form an interface or a class that is able to parse those multiple options
openAPI templates were updated to 7.8.0

Feature scope:

  • oneOf support

Definition of Done

@CharlesDuboisSAP CharlesDuboisSAP self-assigned this Nov 21, 2024
@CharlesDuboisSAP CharlesDuboisSAP added please review Request to review a pull request do not merge Pull request must not be merged labels Nov 21, 2024
@CharlesDuboisSAP CharlesDuboisSAP enabled auto-merge (squash) November 26, 2024 08:16
Comment on lines +121 to +132
/**
* Generate model classes. Default is true.
*/
@Parameter( property = "openapi.generate.generateModels", defaultValue = "true" )
private boolean generateModels;

/**
* Generate API classes (client classes). Default is true.
*/
@Parameter( property = "openapi.generate.generateApis", defaultValue = "true" )
private boolean generateApis;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Question)

Why not have this as separate PR? It's unrelated to oneof / anyof.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to save time

true,
6,
Map.of("useOneOfInterfaces", "true")),
GENERATE_APIS(
Copy link
Contributor

@newtork newtork Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Comment)

Not really sure, whether it's good to mix testing scopes of generate-api and anyof/allof/oneof.
But I'm not objecting at this point. You're just reusing the same spec file.

release_notes.md Outdated

- Add support for `TypeDefinition` entries in OData V4 EDMX files.
- OpenAPI generator improvements:
- Add `oneOf`, `anyOf` and `allOf` support for OpenAPI generation.
Copy link
Contributor

@newtork newtork Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Major)

I'll check the PR in AI SDK, but still it would be good to have a proper unit test in this repo, checking whether serialization and deserialization works at runtime. We are not even testing whether compilation works, right?

Otherwise, looks good!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking for compilation in the sample

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this is a hidden feature in the additional parameters. It should receive the same tests as your pojoBuilder

Copy link
Contributor

@newtork newtork Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking for compilation in the sample

Please link the sample that is being compiled.

this is a hidden feature in the additional parameters

I think this is incorrect, "enableOneOfAnyOfGeneration" is a well documented, publicly suggested and already used feature. It's not considered hidden compared to the pojoBuilder.


If we claim new and better support for oneof, anyof and allof - then we should have them tested for deserialization/serialization. If I see correctly the openapi-api-sample module only tests for allof currently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't change enableOneOfAnyOfGeneration but I added useOneOfInterfaces

Copy link
Contributor Author

@CharlesDuboisSAP CharlesDuboisSAP Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can see that the existing Test/input-spec-with-anyof-oneof/RootObjectQuestionsInner.java didn't change

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's somewhat odd to add useOneOfInterfaces in addition to enableOneOfAnyOfGeneration. It somewhat hides this new functionality from users. How much of a breaking change would it be to always enable the interfaces when enableOneOfAnyOfGeneration is defined?

Also agreeing with @newtork: We need tests in the sample code to ensure compilation actually works. Integration testing this isn't sufficient.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a deserialization test in the sample app

Copy link
Member

@MatKuhr MatKuhr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some comments, most importantly though I think we need a compilation and a runtime check, i.e. sample code and test assertions on (de-) serialization

@@ -0,0 +1,63 @@
openapi: 3.0.0
info:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we have this spec file twice now? Also, why not re-use the existing DataModelGeneratorIntegrationTest/input-spec-with-anyof-oneof/input/AggregatorNestedSchemaChild.json ?

I know we already have a rather bloated test setup here, with much duplication, but adding more to it will cause PR diffs to get larger and larger..

</executions>
<configuration>
<inputSpec>${project.basedir}/src/main/resources/sodastore.json</inputSpec>
<inputSpec>${project.basedir}/src/main/resources/sodastore.yaml</inputSpec>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Question)

Why did you change from json to yaml?
Only for flavor, or does anyof/oneof not work for json?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flavor, the file is shorter

Co-authored-by: Alexander Dümont <[email protected]>
newtork
newtork previously approved these changes Nov 27, 2024
@CharlesDuboisSAP CharlesDuboisSAP added please merge Request to merge a pull request and removed do not merge Pull request must not be merged labels Nov 27, 2024
Copy link
Member

@MatKuhr MatKuhr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise lgtm

/**
* OneOfWithDiscriminatorAndMapping
*/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, this shouldn't be there, since it leads to "@type" fields during serialisation. In the AI SDK this is manually suppressed via mixins. It would be better to not generate this or mark it as disabled. Regardless of what we do, probably a serialisation test would be good

@CharlesDuboisSAP CharlesDuboisSAP merged commit 7e010e4 into main Nov 27, 2024
13 checks passed
@CharlesDuboisSAP CharlesDuboisSAP deleted the oneOf branch November 27, 2024 15:13
@MatKuhr MatKuhr mentioned this pull request Dec 2, 2024
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

please merge Request to merge a pull request please review Request to review a pull request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants